[GraphQL] 개념 잡기

Posted on February 03, 2021

개념 잡기

종합설계프로젝트 1 수업에서 우연찮게 GraphQL을 사용해 봤으나 정확하게 알고 쓴 것도 아니라서 프로젝트가 끝이 난 지금 좀 더 명확하게 개념을 잡고 확실히 사용하는 방법을 익히고 싶었다. 그래서 이번 기회에 이렇게 GraphQL에 관해서 자세하게 정리를 해볼 셈이다.

GraphQL이란?

GraphQL 소개 웹페이지를 들어가보게 되면 가장 먼저 눈에 띄는 문구는 ‘API를 위한 쿼리 언어’ 라고 소개해둔 곳이다.

이 말처럼, GraphQL은 API를 위한 쿼리 언어로 서버사이드 런타임이다. 페이스북에서 만들어진 언어이며 꾸준히 사용빈도며, 인기가 상승하고 있는 현황이다.

쿼리 언어라고 하면 크게 와닿지 않을텐데, 쉽게 얘기해서 sql이란 데이터베이스의 데이터에 접근하기 위한 언어라고 하면, gql이란 클라이언트가 서버로부터 데이터를 요청하는 언어라고 할 수 있다.

언어 자체는 query, mutation, subscription 등 자세하게 살펴보며 익혀보겠지만 다양한 쿼리 문답 형식들이 json 형태를 띄고 있어 매우 친숙해 보인다.

나도 많이 사용해본 것은 아니지만, 분명 GraphQL은 REST API가 가지고 있지 않은 장점들을 가지고 있다.

이번 챕터에서는 GraphQL과 REST 사이의 차이점과 장단점들을 가볍게 훑어보고 graphQL을 사용할 시 어떠한 장점을 극대화해야 할지 생각해보자.

REST API의 문제점.

REST api의 경우 모든 resource들의 각각의 endpoint를 가지고 있다.
이러한 특징은 단순한 서비스에서는 매우 간편하게 사용이 가능하지만, 서비스가 복잡해질수록 Over-fetching과 Under-fetching이 발생한다.
Over-fetching
- 필요로 하는 데이터의 양보다 더 많은 데이터를 가져오는 것.
```
{
    id:1,
    name:"ostar",
    major:"computer science",
    hobby:[
        "dance",
        "music",
        "weight training"
    ]
}
```
- 이런 종류의 데이터가 호출될 때, 정작 클라이언트가 필요한 데이터가 이름과 전공 뿐이라면 Over-fetching으로 인해 리소스가 낭비되는 것이다.
- 적은 양의 데이터 호출에는 상관없겠지만 많은 트래픽이 오가는 사이트라면 이러한 리소스 낭비를 무시하지 못할 것이다.
Under-fetching
- 하나의 end point에 요청한 데이터가 모두 포함되어 있지 않을 때 여러 end point를 요청해야 하는 상황
- GET user/{id} 를 통해 id를 얻었지만 해당 학생의 이름과 전공 정보를 더 구하려고 할 때에는 GET user/info 와 같이 여러번의 요청을 중첩해서 요청해야하는 문제점이 있다.

GraphQL의 효과적인 문제 극복

GraphQL에서는 REST API의 Over-fetching, Under-fetching 현상을 굉장히 효과적으로 극복해냈다.

query{
    user(user_id:1){
        user_name
        user_major
        user_age
    }
}

구체적인 문법들은 차근차근 살펴보겠지만 다음의 query문과 같이 클라이언트는 서버에게 필요한 정보들만을 선별해서 요청할 수 있다. 따라서 리소스의 낭비는 물론이고 client의 개방성이 매우 넓어지는 장면인 것이다.

오늘의 정리

GraphQL에 대해서 개념은 확실히 잡고 가야 나중에 구체적인 문법을 다루더라도 뿌리가 튼튼할 것 같다는 마음에 여러 블로그와 공식 홈페이지를 참조해 보았던 것 같다.

GraphQL을 한번 맛보기삼아 사용해보긴 했으나 아직은 확실히 GraphQL의 장점들이 몸에 와닿지는 않는 것 같다.

또 분명 GraphQL이 REST 보다 월등히 낫다라고 말할 수도 없는 것 같다.

두 방식에는 큰 차이점이 존재하고 양 쪽 모두가 장단점을 가지고 있는 것은 분명한 것 같다.

다만, GraphQL 방식이 프론트엔드 개발자들에게는 개방성을 열어주고 엔드포인트를 전보다는 덜 신경쓰고 개발할 수 있게 방향이 바뀌고 있지 않나 라는 생각이 든다.

Web

GraphQL